MSM delegation by Benny Pinkas
ZKP Seminar — Luca Dall’Ava, 1st of December 2025
Aim: Present a delegation protocol recently devised (posted on February 14, 2025) by Benny Pinkas in [P25].
Introduction and preliminary considerations
There are several protocols suited for delegation of heavy computations like and in [BMMTV19] and improved versions in [CGGJMT23]: these protocols are used in Bulletproofs [BBBPWM17]. However, these rely on a trusted party or on expensive verification (see [J24] for example), while the protocol proposed by in [P25] explicitly work with an untrusted party.
Let be a finite field and let be the group of -rational points of an elliptic curve defined over .
Notation: We follow [P25] and write with multiplicative notation.
Aim of the protocol:
Given public and :
- an untrusted prover computes the Multi-Scalar Multiplication (MSM)
and
- a verifier verifies that the quantity computed and provided by the prover is performed correctly, without computing the whole MSM.
Remark and Notation:
- We can assume that the exponents .
- We denote by the bit-length of the exponents ; we can assume that these are picked uniformly at random in and consider .
The main algebraic manipulations behind the protocols are:
- the binary expansion of each :
- and the manipulation:
That is, we collect products in buckets depending on the corresponding power of .
Therefore, we end up with values , :
Thus, the MSM can be written as
Remark:
- Recall that each , therefore we have MSMs with trivial scalars.
- Provided the ’s, we can compute with multiplications and squarings as
Note that this resembles Horner’s method for evaluating a polynomial (https://en.wikipedia.org/wiki/Horner%27s_method):
Cryptographic Assumptions
Notation: Let be a security parameter.
Assumption 0:
We assume .
The protocol is based on two main assumptions, a first one, due to cryptographic reasons, while the second one for performance improvements.
Assumption 1:
A crucial assumption in [P25] is that the group has an order that does not have small factors.
- Mathematically, we want that the order of each (non-unit) element is big enough, that is, at least .
- An example (which is perfect for the Tokamak Network ZKP) is that of the group associated with the elliptic curve BLS12-381 [B17] which has prime order.
Assumption 2:
We assume that the multi-exponentiation uses exponents that are uniformly distributed, or at least that the expected value of the exponent is close to the order of the group.
This assumption is not relevant for the protocol per se, but it is crucial for the performance improvements.
The Protocol
As stated above, the aim of the protocol is
- for a Prover to convince that it computed correctly the MSM and
- for a Verifier to verify the Prover’s statement without computing the whole MSM.
The second step is the crux in the wholes scheme, as we are working under a third hypothesis.
Assumption 3:
The party working as the Prover is not-trusted.
We can now present the protocol and discuss its security proofs.
Protocol: Delegated Partial MSM —
Prover and Verifier input:
- public ;
- public .
Output:
- Purported MSM partial values ,
- or , representing the authenticity of (all) the equalities .
- computes, for each :
- computes, for each :
- sends the values .
- chooses random coefficients (that is, number of -bits).
- computes the length- MSM with exponents of bits:
- computes the length- MSM with exponents of bits:
- checks
and if the equality holds, returns . Otherwise, it returns .
Once protocol has been performed, the verifier is convinced (with probability at least ; see Lemma ) that the MSMs have been correctly computed.
Therefore, the verifier can compute
Proposition (Completeness):
The protocol is complete.
Proof:
It is enough to notice (again) that
Lemma:
Given a group , what is the probability that a product of , uniformly picked at random group elements is the unit ? It is
Proof:
We proceed on induction on .
- If , the claim is trivial and equality holds.
- Similarly, for , the claim is obtained from the fact that there exists a unique inverse for each group element. Equality holds.
- Let us assume the claim for and prove it for .
Now, the probability, by Bayes’ Theorem, is
Lemma:
In the protocol , provided that the random values are independent, the probability that the quantities and are equal given that not all values are computed correctly is
Proof:
We can write
and compare it with .
Now, suppose that there exists a such that ; WLOG we can fix . Since is a group we can write:
Therefore, written , we can apply the above Lemma , since
- , by hypothesis, and therefore, its (unique) inverse is non-trivial;
- we can assume that the are independent since the are;
- since the group has order without small factors as in (one can consider prime order) and the exponents have at most bits, (and therefore, its unique inverse is non-trivial).
Therefore we have
Proposition:
The protocol is sound.
Proof:
The soundness is proved by the above Lemma, with soundness error .
Drawbacks of the protocol
This protocol makes sure to work with an untrusted prover, however, it has its own drawbacks.
On the randomness and the security parameter
It is important to notice that, in the security proof, we make a strong use of the assumption
The selected random exponents are independent and provided by the verifier.
Pinkas warns, as one should be aware of, that applying the Fiat—Shamir transform:
- the security proofs are, strictly speaking, no more valid,
- in this setting, should be picked to be, at least, .
When the Fiat-Shamir proof paradigm is used, a prover can mount a brute-force search for a challenge, namely a set of exponents that makes the proof pass. Therefore, the analysis given here does not hold when the exponents are chosen by the prover using the Fiat-Shamir paradigm. (In that case, the security parameter should be set to be at least .) The correct procedure involves the verifier selecting the random exponents and executing the computations using these values.
Some other references about the delicate topic of the Fiat-Shamir transform and some attacks:
Overhead in the protocol
The protocol’s Verifier incurs in some overhead consisting of:
- calls to a random oracle box (that is, number of -bits); producing hashes is expensive on the Ethereum L1.
- length- MSM with exponents of bits: ; minor, .
- length- MSM with exponents of bits: ; main overhead.
Then the verifier can compute:
- final MSM computed as (consisting of squarings and multiplications (circa R1CS equations)).
Let us quote:
Since the overhead of the multi-exponentiation is linear in the length of the exponents, performance is roughly improved by a factor of .
Remark (Question):
In terms of R1CS constraints, is a length- MSM with exponents of bits cheaper than a length- MSM with exponents of bits if .
Some numerical considerations
The protocol provides some gains only when . In the Tokamak ZKP Channel, we have:
- can be taken big enough, a long as the security proof hold true ( in), e.g. , etc..
- (since the BLS12-381 group has prime order with bits)
- .
Pinkas computes,
- on a MacBook Pro M1,
- based on the above numbers, and
- considering the Pippinger Algorithm implemented in Rust by Zhoujun Ma here,
the runtime, in milliseconds (the median of 100 runs) of the computation of the length- MSM with exponents of -bits over the BLS12-381 curve.
| / exp length | 16 | 32 | 64 | 128 | 256 |
|---|---|---|---|---|---|
| 1000 | 1.92 | 3.56 | 6.74 | 13.32 | 25.95 |
| 2000 | 3.06 | 6.19 | 12.36 | 24.62 | 48.28 |
| 4000 | 5.76 | 12.11 | 22.48 | 43.15 | 83.53 |
| 8000 | 10.93 | 22.47 | 41.80 | 82.57 | 162.81 |
Then, he computes, for
- ,
- the runtime (in milliseconds, the median of 64 runs), and the gains,
- for the exponent lengths of ,
of the value and compare it with the whole MSM .
| n | λ=40, exp len = 48, runtime | λ=40, exp len = 48, gain | λ=64, exp len = 72, runtime | λ=64, exp len = 72, gain | exp len = 255, runtime |
|---|---|---|---|---|---|
| 1,000 | 4.72 | 5.36 | 7.3 | 3.46 | 25.28 |
| 4,000 | 15.9 | 5.00 | 22.4 | 3.55 | 79.49 |
| 16,000 | 51.66 | 5.53 | 81.38 | 3.51 | 285.85 |
| 64,000 | 173.43 | 5.43 | 259.03 | 3.64 | 942.09 |
| 256,000 | 676.1 | 4.79 | 989.05 | 3.28 | 3241.4 |
| 1,024,000 | 2321.2 | 5.25 | 3702.4 | 3.29 | 12192 |
| Ideal gain | 5.31 | 3.54 |
Questions to be investigated
We are left with a few questions that we wish to answer:
- Can we verify multiple MSMs at the same time?
- I believe so, but we need to introduce further random values.
- How efficient is this approach for verification on a Layer 1 blockchain like Ethereum?
- Can the protocol be further improved?
Further application issues
- Ethereum has some precompiled contracts handling BLS12-381 MSMs: https://www.evm.codes/precompiled. Unfortunately, they do not depend on the bit-length of the exponents, thus, making handling smaller length exponents a too small improvement.
References:
- [B17] - Sean Bowe, BLS12-381: New zk-SNARK elliptic curve construction. https://electriccoin.co/blog/new-snark-curve/, March 2017.
- [BBBPWM17] - Benedikt Bünz and Jonathan Bootle and Dan Boneh and Andrew Poelstra and Pieter Wuille and Greg Maxwell, Bulletproofs: Short Proofs for Confidential Transactions and More, Cryptology ePrint Archive, Paper 2017/1066, 2017, https://eprint.iacr.org/2017/1066
- [BMMTV19] - Benedikt Bünz, Mary Maller, Pratyush Mishra, Nirvan Tyagi, and Psi Vesely, “Proofs for Inner Pairing Products and Applications”, Cryptology ePrint Archive, 2019, https://eprint.iacr.org/2019/1177
- [CGGJMT23] - Campanelli, M., Gailly, N., Gennaro, R., Jovanovic, P., Mihali, M., & Thaler, J. (2023). Testudo: Linear Time Prover SNARKs with Constant Size Proofs and Square Root Size Universal Setup. IACR Cryptology ePrint Archive, Report No. 2023/961, https://eprint.iacr.org/2023/961
- [J24] - Jehyuk Jang, TIPP: Inner pairing products. Tokamak Network ZKP Research Seminar, Notion, https://www.notion.so/TIPP-Inner-pairing-products-12ed96a400a380d189dcdfca37544740?pvs=21
- [P25] - Benny Pinkas, Verifiable Multi-Exponentiation and Multi-Scalar Multiplication (MSM). Decentralized Thoughts (2025, February 14). https://decentralizedthoughts.github.io/2025-02-14-verifiable-MSM/
